Adds a Data Breach History check, via Have I Been Pwned - #334

What this does

Web Check tells you how a site is configured today. It says nothing about whether the service behind it has already lost its users' data — which is often the more useful thing to know when you are judging a vendor, or working out whether credential stuffing is a live risk for a login page.

This adds a Data Breach History check against the public Have I Been Pwned breach catalogue: which incidents are on record for the domain, when, how many accounts, and which classes of data were exposed.

No API key. The /api/v3/breaches?domain= endpoint is unauthenticated, so this works on every self-hosted instance out of the box, with nothing to configure.

Privacy — deliberately the domain-level catalogue only

HIBP exposes three easily-confused things. This uses only the first:

Only the registrable domain leaves the server. No email address, account or password is submitted, and the check makes no claim about any individual user's data.

Three things the raw feed does not give you for free

1. Subdomains silently miss. HIBP indexes against the registrable domain, so store.adobe.com returns [] while adobe.com returns the breach. The hostname is folded down with psl, the same way whois.js and subdomains.js already do it.

2. Descriptions contain real markup, including anchors with target="_blank":

...password and a password hint in plain text. The unencrypted hints also
<a href="http://www.troyhunt.com/..." target="_blank" rel="noopener">disclosed
much about the passwords</a> adding further to the risk...

Rendering third-party HTML is the exact flaw this tool reports on other people's sites, so tags are stripped server-side rather than trusted downstream.

3. The catalogue is not all equally credible. Of the 1026 entries currently published, 42 are unverified, 3 fabricated, 16 spam lists and 6 stealer logs. Those are kept — hiding them would be its own distortion — but flagged, so a fabricated entry is never shown with the weight of a confirmed one.

Exposed data classes are tiered by how damaging they are (credentials and financial records, then data enabling targeted attacks, then plain identifiers), which drives both the ordering and the colour coding.

Example

linkedin.com, through the live endpoint:

domain=linkedin.com  breaches=3  accounts=310,098,844  worst=critical  latest=2023-11-04
  - LinkedIn                             2012-05-05  critical  trust=true
      Passwords[critical] Email addresses[medium]
  - LinkedIn Scraped Data (2021)         2021-04-08  medium    trust=true
      Email addresses[medium] Geographic locations[medium] Names[medium] ...
  - LinkedIn Scraped and Faked Data (2023) 2023-11-04 medium   trust=false
      Email addresses[medium] Geographic locations[medium] Names[medium] ...

The faked 2023 entry sorts last and is badged "unconfirmed" rather than presented as a breach.

Advisory integration

A catalogued breach is history, not a live misconfiguration, so it is deliberately never reported as critical — putting a 2012 breach beside "MySQL exposed to the internet" would misrepresent what actually needs attention today. Instead:

• credentials exposed in a confirmed breach → issue, with advice to force a reset and watch for credential stuffing
• other confirmed breaches → warning
• unverified / fabricated / spam-list entries → info
• nothing on record → pass

Tests

28 unit tests using the built-in Node test runner — no new dependencies, no config file. They cover domain folding (including multi-part suffixes like .co.uk), HTML stripping and entity decoding, data-class tiering, sorting, the trust flags, and the malformed-input paths.

yarn test   # node --test
ℹ tests 28
ℹ pass 28
ℹ fail 0

A 🧪 Unit Tests job is wired into .github/workflows/ci.yml alongside the existing lint and typecheck jobs.

Verification

• yarn test — 28/28
• yarn lint — clean
• yarn typecheck (astro check) — 0 errors, 0 warnings, 0 hints
• yarn build — completes
• prettier --check on every touched file — clean
• Live end-to-end runs through the real route and middleware: adobe.com, store.adobe.com (proving the subdomain fold), a full https://www.linkedin.com/feed URL, a clean domain, and an IP (correctly skipped)
• Card and Advisory rule both exercised against live HIBP responses

Notes

• Most domains return nothing, which is the expected result. The card reports that explicitly rather than hiding, matching how the vulnerabilities card reports a clean host.
• HIBP publishes under CC BY 4.0, so attribution and the licence link ship with the response rather than being hardcoded in the component.
• A clean result means only that no breach has been catalogued against the domain — not that none occurred. That caveat is stated in the in-app docs and the README.
• Small overlap with CVE panel 2.0: CISA KEV, EPSS and exposure context #333: both add the same one-line test script to package.json and the same CI job. Whichever lands first, the other reduces to a trivial conflict. Everything else here is new files or additive registry entries.